A typical standard networking system implemented single-function, fixed functionality. The first generation of virtualized systems offers per-customer functionality, but the functionality is still fixed. These limitations lead to several drawbacks. Customers may judge service providers based on service availability. Customers may perceive any downtime as a problem with the service provider and may consider switching providers. Service providers want to add service products to their offerings to generate more revenue and increase margins with higher-value offerings. Some of today's systems require downtime associated with upgrades. This is the case because their systems package all functionality into a single runtime image. It is simpler to design and test a system when all functionality is packaged and released in a single unit. In some cases, the service provider has to minimize downtime by building a redundant topology and taking down one system while the backup system handles service. This is non-optimal because it forces the service provider to purchase redundant hardware and design complex configurations. To achieve economies of scale and lower capital expenditures, service providers are installing systems that service multiple customers on a single system. Rather than dedicating hardware to each individual customer, the service provider amortizes that capital expense across many customers, lowering the average cost. These service providers typically schedule downtime with their customers for routine maintenance. This scheduling is more difficult when multiple customers are configured to utilize the same system.
In addition, typical networking systems may offer fixed functionality that is composed in a fixed manner. For instance, processing is usually L2 followed by L3, or SSL acceleration followed by load balancing. Typically, networking systems implement fixed functionality with a monolithic version of software. Those systems that offer Virtual loading typically use a simple link-time configuration strategy or simple Virtual loading at start time, but not thereafter. Thus, you may get to choose what functionality you want to run at startup time, but you cannot change it thereafter. Typically, prior systems have had disadvantages such as they require a reboot when they are upgraded. This causes downtime. As a result, some conventional systems lack the ability to configure functionality in an arbitrary manner using an arbitrary topology, to add new functionality to a running system without causing downtime, or to upgrade a portion of functionality to a new revision.
Furthermore, When identifying a set of packets as a related flow in order to expedite packet handling, a common set of header fields used for transmission control protocol/user datagram protocol (TCP/UDP) flows includes the following: source IP address, destination IP address, source port number, destination port number, and protocol. This set of five fields uniquely identifies a TCP or UDP flow in an IP-based network.
When attempting to use this mechanism on a system that is providing a virtualized set of network components, collisions can occur if the virtualized network components have overlapping IP address spaces. This situation is likely to occur in the presence of Network Address Translation (NAT), which enables private addresses to be used behind network firewalls. If a system provides NAT-capable networking components in a virtualized environment, then the previously described set of five header fields may not uniquely identify a single flow.
A frequently used mechanism for matching a packet to a previously recognized flow of packets is to use a hash of a common set of header fields. In order to match forward and reverse packets for the same session, the hashing algorithm can eliminate the order dependencies between the source and destination header fields (e.g. exclusive OR the fields). Unfortunately, this approach fails to coordinate forward and reverse packets when Network Address Translation (NAT) has been applied because there may not be a correlation between the source and destination header fields for the forward and reverse packets.
One solution to this problem is to match the forward and reverse packets using separate hash tables. The sibling flows (the originating packet direction is considered forward, and the response is reverse) can be tied together using symmetric references. Unfortunately, this scheme requires that a packet be identified as forward or reverse prior to the attempted match, which reduces the flexibility in the configuration of the system (e.g. physical interfaces need to be classified as receiving either forward or reverse packets, but not both).
Therefore, a better solution is highly desirable to be able to compose, manage, change, or upgrade a topology of a network system.